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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 



Introduction 



TS 102 778-3 [1] (PAdES-3 henceforth) and TS 102 778-4 [9] (PAdES-4 henceforth) specify formats for Advanced 
Electronic Signatures built on PDF ISO-32000 [2]. That document defines a number of signed and unsigned optional 
signature properties, resulting in support for a number of variations in the signature contents and powerful processing 
requirements. 

In order to maximise interoperability in communities applying PAdES to particular environments it is necessary to 
identify a common set of options that are appropriate to that environment. Such a selection is commonly called a 
profile. 

The present document profiles TS 101 903 [11] signatures contexts where AdES signatures are used and in particular its 
use in the context of the "Directive 2006/123/EC [i.2] of the European Parliament and of the Council of 12 December 
2006 on services in the internal market" (EU Services Directive henceforth). 
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Scope 



The present document defines a baseline profile for XAdES that provides the basic features necessary for a wide range 
of business and governmental use cases for electronic procedures and communications to be applicable to a wide range 
of communities when there is a clear need for interoperability of AdES signatures used in electronic documents to be 
interchanged across borders. In particular it takes into account eSignature needs in the context of the EU Services 
Directive [i.l]. 

The profile defines four different conformance levels addressing incremental requirements to maintain the validity of 
the signatures over the long term, in a way that all the requirements addressed at a certain level are always addressed 
also by the levels above. Each level requires the presence of certain PAdES attributes, suitably profiled for reducing the 
optionality as much as possible and referring to the forms that are specified in PAdES [1] and [9]. 

Clause 4 identifies the four conformance levels and shows how these levels might encompass the life cycle of the 
electronic signatures. 

Clause 5 provides details on the way that the requirements will be presented throughout the present document. 

Clause 6 profiles short-term related PAdES attributes. 

Clause 7 profiles a PAdES signature for which a Trust Service Provider has generated a trusted token (time-mark or 
time-stamp token) proving that the signature itself actually existed at a certain date and time. 

Clause 8 profiles long-term related PAdES attributes tackling the long term availability of the signature validation 
material. 

Clause 9 profiles long-term related PAdES attributes tackling the long term availability and integrity of the signature 
validation material. 

NOTE: The present document makes use of certain verbal forms (e.g. may, shall, shall not and should) as key 
words to signify requkements, conforming to ETSI Drafting Rules, clause 14a [i.7]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 778-3: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic 

Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles". 

NOTE: Available as ISO Standard or directly from Adobe's PDF Reference 

http ://w w w . adobe. CO m/devnet/pdf/pdf reference . html in especially part 1 clause 12.8 can be retrieved 
from http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000 2008.pdf . 

[2] ISO 32000:2008 (all parts): "Document management - Portable document format". 

NOTE: Available at http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000 2008.pdf . 
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[3] ETSI TS 101 733: "Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic 

Signatures (CAdES)". 

NOTE: Available at " http://www.etsi.org/deliver/etsi ts/101700 101799/101733/ . 

[4] IETF RFC 3852 (2004): "Cryptographic Message Syntax (CMS)". 

NOTE: Available at http://tools.ietf.org/rfcmarkup/3852 . 

[5] IETF RFC 2634 (1999): "Enhanced Security Services for S/MIME". 

NOTE: Available at http://tools.ietf org/rfcmarkup/2634 . 

[6] IETF RFC 5035 (2007): "Enhanced Security Services (ESS) Update: Adding CertID Algorithm 

AgiUty". 

NOTE: Available at http://tools.ietf org/rfcmarkup/5035 . 

[7] ETSI TS 102 176-1: "Electrorric Signatures and Infrastructures (ESI); Algorithms and Parameters 

for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms". 

NOTE: Available at http://www.etsi.org/deliver/etsi ts/102100 102199/10217601/ . 

[8] ECRYPT II (European Network of Excellence in Cryptology II): "ECRYPT II Yearly Report on 

Algorithms and Keysizes". 

[9] ETSI TS 102 778-4: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic 

Signature Profiles; Part 4: PAdES Long Term - PAdES LTV Profile". 

NOTE: Available at http://www.etsi.org/deliver/etsi ts/102700 102799/10277804/ . 

[10] ETSI TS 103 173: "Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile". 

NOTE: Available at http://www.etsi.org/deliver/etsi ts/103100 103199/103173/ . 

[11] ETSI TS 101 903: "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic 

Signatures (XAdES)". 



2.2 



Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 



[i.l] 

[i.2] 
[i.3] 

[i.4] 
[i.5] 
[i.6] 



Commission Decision 201 1/130/EU of 25 February 201 1 ; establishing minimum requirements for 
the cross-border processing of documents signed electronically by competent authorities under 
Directive 2006/1 23/EC of the European Parliament and of the Council on services in the internal 
market (notified under document C(201 1) 1081). 

Directive 2006/1 23/EC of the European Parliament and of the Council of 12 December 2006 on 
services in the internal market. 

Commission Decision 2009/767/EC of 16 October 2009 amended by CD 2010/425/EU of 28 July 
2010 setting out measures facilitating the use of procedures by electronic means through the 
'points of single contact' under Directive 2006/123/EC of the European Parliament and of the 
Council on services in the internal market. 

ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 
Trust-service status information". 

ETSI TS 101 533-1: "Electronic Signatures and Infrastructures (ESI); Data Preservation Systems 
Security; Part 1: Requirements for Implementation and Management". 

ETSI TS 102 640-1: "Electrorric Signatures and Infrastructures (ESI); Registered Electronic Mail 
(REM); Part 1: Architecture". 
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[i.7] ETSI Drafting Rules (EDRs). 

NOTE: Contained in the ETSI Directives: http://portal.etsi.org/Directives/home.asp . 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
generator: any party which creates, or adds attributes to, a signature 

NOTE: This may be the signatory or any party that initially verifies or further maintains the signature. 
protocol element: element of the protocol which may be including data elements and / or elements of procedure 
service element: element of service that may be provided using one or more protocol elements 

NOTE: All alternative protocol elements provide an equivalent service to the users of the protocol. 
trust service provider: body operating one or more (electronic) Trust Services 

NOTE: See [i.4]. 
verifier: entity that validates or verifies an electronic signature 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in PAdES-3 [1] and the following apply: 
TSL Trust Status List 

NOTE: See [i.4]. 



Conformance Levels 



The present specification defines four conformance levels as indicated below. 

Applications managing signatures conformant to requirements specified in clause 6 may claim B-Level (basic level) 
conformance. 

Applications managing signatures conformant to B-Level and also conformant to requirements specified in clause 7 
may claim T-Level (Trusted time for signature existence) conformance. 

Applications managing signatures conformant to T-Level and also conformant to requirements specified in clause 8 of 
the present document may claim LT-Level (Long Term level) conformance. 

Applications managing signatures conformant to LT-Level and also conformant to requirements specified in clause 9 of 
the present document may claim LTA-Level (Long Term with Archive time-stamps) conformance. 

These conformance levels are defined for encompassing the life cycle of electronic signature, namely: 

a) B-Level profiles incorporation of signed and some unsigned properties when the signature is actually 
generated. 

NOTE 1: It is considered that this level is sufficient to conform to the Commission Decision 201 1/130/EU of 
25 February 2011 [i.l]. 

b) T-Level profiles the generation, for an existing signature, of a trusted token proving that the signature itself 
actually existed at a certain date and time. 
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c) LT-Level profiles the incorporation of all the material required for validating the signature in the signature. 
This level is understood to tackle the long term availability of the validation material. 

d) LTA-Level profiles the incorporation of time-stamp tokens that allow validation of the signature long time 
after its generation. This level is understood to tackle the long term availability and integrity of the validation 
material. 

NOTE 2: The levels b) to d) are appropriate where the technical validity of signature needs to be preserved for a 
period of time after signature creation where certificate expiration, revocation and/or algorithm 
obsolescence is of concern. The specific level applicable depends on the context and use case. 

All conformance levels up to LTA use attributes defined in PAdES [1] and [9] and underlying specifications. 

When signed data is exchanged between parties the sender should use at least signatures conforming to a level that 
allows the relying parties to trust the signature at the time the exchange takes place. 

NOTE 3: Archiving or preservation of electronic signatures over long term requires in general conformance to LTA 
level. The use of LTA-level is considered an appropriate preservation and transmission technique for 
signed data. Conformance to lower level is sufficient when combined with appropriate additional 
protection techniques such as use of systems compliant to TS 101 533-1 [i.5]. 

NOTE 4: The assessment of the effectiveness of other preservation and transmission techniques for signed data are 
out of the scope of the present document. The reader is advised to consider legal instruments in force and 
related standards such as TS 101 533-1 [i.5] or TS 102 640-1 [i.6] to evaluate their appropriateness. 



5 General requirements 

5.1 Algorithm requirements 

Generators are referred to applicable national laws regarding algorithms and key lengths. 

Generators are also recommended to take into account the latest version of TS 102 176-1 [7] for guidelines purposes 
and the latest ECRYPT2 D.SPA.x [8] yearly report for further recommendations, when selecting algorithms and key 
lengths. 

MD5 algorithm shall not be used as digest algorithm. 

5.2 Compliance requirements 

Profiles in the present document define requirements for generators of PAdES signatures [1] and [9]. 

A verifier shall be able to accept a signature containing any elements/properties conformant to PAdES [1] and [9], but 
this profile does not specify any processing requirement on such elements/properties present in the signature as it is 
meant to be used together with a specification describing processing during signature validation. 

Requirements are grouped in four different categories, each one having its corresponding identifier. Table 1 defines 
these categories and their identifiers. 

Table 1 : Requirement categories 



Identifier 


Requirement on generator 


M 


Generator shall include the element in 
the signature. 





Generator may include the element in 
the signature. 



Optional elements defined in PAdES-3 [1] but not specified in the present document are treated as "O" as above. 
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Certain service elements may be provided by different protocol elements at user's choice. In these cases the semantics 
of M and O defined in the table above depend on the requirement for the service element itself. Tables 2 and 3 (each 
one applies to a different requirement on the service element) define these semantics. 

Table 2: Requirements for mandatory service with choices 



Requirement Identifier 
for the Service / 
Protocol element 


Requirement on generator 


Service = M 


Generator shall provide the service by including 
one protocol element chosen from the list of 
choices. 


Protocol Choice = 


Generator may use this protocol element for 
providing the mandatory service elements. 



Table 3: Requirements for optional service with choices 



Requirement Identifier 
for the Service / 
Protocol element 


Requirement on generator 


Service = 


Generator may provide the service by including one 
protocol element chosen from the list of choices. 


Protocol Choice = 


If the generator decides to provide the service, then 
she may use this protocol element. 



The present document shows new requirements for each service and protocol element in tabular form. Below follows 
the structure of the table. 

Table 4: Requirements for optional service with choices 



Service / Protocol 
element 


Reference 


Requirement on 
generator 


Additional 
requirements / notes 


Service: 








Choice 1 








Choice 2 









Column Service / Protocol element will identify the service element or protocol element the requirement applies to. 
Service elements that may be implemented by different protocol elements (i.e. users may make a choice on several 
protocol elements) build tables with more than one row. 

Column Reference will reference the relevant clause of the standard where the element is first defined. The reference is 
to PAdES-3 [1], except where explicitly indicated otherwise. 

Column Requirement on generator will contain an identifier of the requirement, as defined in table 1 , bound to the 
corresponding protocol element for the generator. 

Column Notes / Additional requirements will contain numbers referencing notes and/or letters referencing additional 
requirements. Both notes and additional requirements are listed below the table. 

Profiles may be affected by applicable regulations; hence implementers should check any national regulation that may 
affect these profiles. 



6 Requirements for B-Level Conformance 

This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil. 

The current clause specifies compliance requirements for short-term electronic signatures. This clause actually profiles 
PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures 
that do incorporate signature-policy-identifier) signatures. 
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All attributes profiled by PAdES Part 3 [1] and specified in ISO 32000-1 [2] apply as stated in those specifications 
unless mentioned here otherwise. Also PAdES Part 3 states that "Requirements for handling PDF Signatures specified 
in ISO 32000-1, clause 12.8 apply except where overridden [...]". The following clauses will apply the same strategy. 

NOTE 1 : Given that PAdES signatures are enveloped inside a PDF document and are detached in the sense of a 
CMS signature, the signature placement is implied by PAdES-3 [1] and ISO 32000 [2]. 
In ISO 32000 [2], section 12.8.3.3.1 reads "No data shall be encapsulated in the PKCS#7 SignedData 
field.", no re-statement will be given here, however readers should be aware of the fact that subtle 
dependencies exist. 

In consequence, the following PAdES properties are addressed directly in this clause: 

SignedData . certificates, the M entry in the signature dictionary (provides a claimed signing 
time like CAdES [3], clauses 5.1 and 5.9.1), signing-certif icate . Further content-type, message- 
digest, signature-policy-identifier, signer-attributes, content-type, content -time - 
stamp and the Location and Reason entries in the signature dictionary are inherently 
addressed. 

NOTE 2: PAdES Part 3 [1] prohibits the use of the attributes signing -time, counter- signature, 
content-reference, content-identifier, content-hints, and signer - 
location. PAdES Part 3 [1] prohibits the use of the attribute commitment-type- indication 
for PAdES-BES and allows its use for PAdES-EPES. 

6.1 Attributes defined in CIVIS Signature 
6.1 .1 Placements of the signing certificate 

Table 5 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 
requirements / notes 


SignedData . certificates 


CMS [4], clause 5.1 


M 


a, b 



Additional requirements: 

a) The generator shall include the signing certificate in the SignedData . certificates field. 

b) In order to facilitate path building, generators should include in the SignedData . certificates field all 
certificates not available to verifiers that can be used during path building. In the case of signature based on 
qualified certificates and whose verification is expected to be based on TSLs (in particular on Trusted Lists as 
defined in CD 2009/767/EC amended by CD 2010/425/EU [i.3])", the generator should include all 
intermediary certificates forming a chain between the signer certificate and a CA present in the TSL which are 
not available to verifiers. 

NOTE 1 : A certificate is considered available to the verifier if reliable information about its location is known and 
allows automated retrieval of the certificate (for instance through an Authority Info Access Extension or 
equivalent information present in a TSL). 

NOTE 2: In the general case, different verifiers can have different trust parameters and can validate the signer 
certificate through different chains. Therefore, generators may not know which certificates will be 
relevant for path building. However, in practice, such certificates can often clearly be identified. In this 
case, it is advised that generators include them unless they can be automatically retrieved by verifiers. In 
the specific case of a signature meant to be validated through TSL, it is advised to include at least the 
unavailable intermediary certificates up to but not including the CAs present in the TSLs, since the TSL is 
information that is shared globally by all verifiers. 
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6.2 



Attributes overridden in PAdES-3 



6.2.1 Signing time 



Table 6 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 

requirements / 

notes 


Service: provide a claimed 
time of signing 


[1], clause 4.5.3 


M 


a 


M entry in the signature 
dictionary 


ISO 32000-1 [2], 
clause 12.8.1 


M 





Additional requirement: 

a) The generator shall include the claimed UTC time of the signature as expressed in [2], clause 7.9.4 as content 
of this element. 



6.3 



Attributes defined in ESS 



6.3.1 Signing certificate 



Table 7 



Service / Protocol element 


Reference 


Generator 
Requirement 


Additional 

requirements / 

notes 


Service: protection of signing certificate 




M 




ESS signing-certif icate 


ESS [5], clause 5.4 





a, b 


ESS signing-certif icate v2 


ESS [6], clause 4 





a,b 



Additional requirements: 

a) Generators shall use either the signing certificate or the signing-certificate v2 attribute, depending on the hash 
function using, in accordance with ESS [6], clause 2. 

b) Generators should migrate to the use of ESS signing-certificate v2 in preference to ESS signing-certificate in 
line with the guidance regarding limited lifetime for the use of SHA-1 given in clause 9.2 of TS 102 176-1 [7]. 



7 Requirements for T-Level Conformance 

This clause defines those requirements that PAdES signatures conformant to B-Level, have to fulfil to also be 
conformant to T-Level. In consequence, PAdES signatures claiming conformance to the T-Level of the present profile 
shall be built on signatures conformant to the B-Level. 

A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service 
Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually 
existed at a certain date and time. 

NOTE: PAdES signatures conformant to T-Level of the present specification are, in consequence PAdES -BES or 
EPES signatures suitably profiled as per the requirements defined in this clause. 
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7.1 



Service as defined in CAdES 



7.1.1 



Trusted time for existence of tine signature 



Table 8 further profiles the provision of the trusted token that proves existence of the signature at a certain date and 
time. The provision of the Service : trusted signing time is profiled as in CAdES Baseline Profile [10] 
clause 7 extended by the option to provide a document-time-stamp in lieu of a signature-time-stamp attribute 
PAdES Part 3 [1], clause 4.5.2 or time -mark. 

Table 8 



Service / Protocol element 


Reference 


Generator 
Requirement 


Additional 
requirements / notes 


Service: trusted time for 
existence of the signature 


[1], clause 4.5.2 
[3], clause 4.4.1 


M 




signature -time -stamp 
attribute 


[1], clause 4.5.2 

[3], clause 6.1 

[3], clause 4.4.1 





a, b, c, d 


time-mark 


[3], clause 4.4.1 





e 


document - time - stamp 


[9], clause A.2 





d 



Additional requirements: 

a) The present profile recommends usage of time-stamps as attestation of the time for existence of the signature 
instead of time-marks. 

b) A PAdES signature claiming conformance to the T-Level may contain several signature-time-stamp 
attributes. 

c) The generator shall use DER encoding for any signature -time -stamp. 

d) The B-Level signatures as profiled in clause 6 shall reserve space for the signature -time -stamp 
attribute [1], clause 4.5.2, if it is anticipated to propagate them to a higher conformance level. Alternatively a 
document -time -stamp can serve this purpose, which covers the whole document including the signature 
value and may be applied before the DSS and DSS/VRI. 

e) If a time-mark is used, then no additional attribute is incorporated in the signature. It is the responsibility of the 
TSP generating the time-mark to provide the needed trust on the signature time. 



8 



Requirements for LT-Level Conformance 



This clause defines those requirements that PAdES signatures conformant to T-Level, have to fulfil to also be 
conformant to LT-Level. In consequence, PAdES signatures claiming conformance to the LT- Level of the present 
profile shall be built on signatures conformant to the T- Level. 

Hence implementations claiming conformance to the LT-Conformance Level build the PAdES -LTV form 
(PAdES Part 4 [9], clause 4) on signatures that shall be conformant to the T-Level requirements and to the present 
clause. 
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8.1 



Profile of ISO 32000-1 LTV Extensions 



8.1 .1 Document Security Store 



Table 9 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 

requirements / 

notes 


Service: certificate and revocation values 




M 




DSS 


[9], clause A.1 


M 


a, b, c, d, e 


DSS/VRI 


[9], clause A.1 





f 



Additional requirements: 

a) The generator shall include the full set of certificates, including the trust anchor when it is available in the 
form of a certificate, that have been used to validate the signature and which are not already present. This set 
includes certificates required for validating the signing certificate, for validating any attribute certificate 
present in the signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) 
already incorporated to the signature. 

b) In situations different than those ones identified in clause 6.1.1 of the present document requirements a) and 
b): applications should include certificate values within the DSS. 

c) The present document recommends to avoid duplication of certificate values within the signature. 

d) The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the 
validation of the signer, and CA certificates used in signature. This set includes all certificate status 
information required for validating the signing certificate, for validating any attribute certificate present in the 
signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already 
incorporated to the signature. 

e) The generator shall use DER encoding for the certificate-values and the revocation-values. 

f) Although VRI is acceptable under this LT-Level, its use should be avoided to maximise interoperability. 



9 Requirements for LTA-Level Conformance 

This clause defines those requirements that PAdES signatures conformant to LT-Level, have to fulfil to also be 
conformant to LTA-Level. In consequence, PAdES signatures claiming conformance to the LTA-Level of the present 
profile shall be built on signatures conformant to the LT-Level. 

A CAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more 
document -time- stamp has been incorporated. 

NOTE: As stated in PAdES Part 4 [9], a LTA form may help to validate the signature beyond any event that may 
limit its validity. 

Table 10 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 

requirements / 

notes 


Service: trusted time for existence of the validation 
data 


[10], clause 9 
[3], clause 6.5 


M 




document - time - stamp 


[9], clause 4 
[9], clause A.2 


M 


a, b,c, 1,2 
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Additional requirements: 



a) Signatures conformant to LTA-level may have more than one document -time- stamp applied after the DSS 

and DSS/VRi . 

b) Before generating and incorporating a document-time-stamp attribute, applications claiming conformance 
to this profile, shall include all the validation material, which are not already in the signature, required for 
verifying the signature. This validation material includes all the certificates and all certificate status 
information (like CRLs or OCSP responses) required for: 

validating the signing certificate; 

validating any attribute certificate present in the signature; and 

validating any time-stamp token's signing certificate (i.e. a TSA certificate) already incorporated to the 
signature (including, of course, any previous document -time -stamp). 

This validation material should be incorporated within DSS. 
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